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WHITE  PAPER 
ON 

ENTERPRISE  TERRAIN  DATA  STANDARDS  FOR  JOINT  TRAINING 

3  October  2017 

Executive  Summary 

The  development  of  digital,  computer-based  training  simulations/simulators  has  evolved  over  the 
last  four  decades,  in  which  early  approaches  were  often  constrained  by  severe  hardware,  software 
and  data  source  limitations.  Simulation  engineers  were  required  to  make  compromises  between  a 
simulation  or  simulators’  targeted  fidelity  and  its  level  of  generality,  scalability,  abstraction,  and 
correlation  with  other  systems.  Community- wide  standardization  could  not  be  achieved  because 
technologically  viable  solutions  only  offered  partial  solutions  to  training  needs.  Consequently,  Joint 
and  Service  simulation  training  capabilities  adopted  or  developed  differing  standards,  often  in 
isolation,  tailored  to  their  specific  training  needs.  This  has  resulted  in  recurring  costly,  manpower 
intensive  integration  efforts  to  link  these  disparate  simulations  together  in  training  federations  to 
meet  joint  training  requirements.  Digital  technologies  have  made  tremendous  strides  in  the  past 
decade  and  are  closing  the  gap  between  what  is  required  for  training  and  what  technology  can  now 
deliver.  With  the  Department’s  direction  to  move  modeling  and  simulation  (M&S)  capabilities  to 
the  DoD  Information  Technology  (IT)  Enterprise  Framework,  the  time  is  right  to  leverage  these 
strides  and  transition  the  Joint  training  enterprise  toward  a  smaller  set  of  common  standards  and 
better  investment  of  our  scarce  resources  towards  common  solutions. 

This  paper  investigates  one  aspect  of  this  larger  problem  set  -  the  cooperative  establishment  of  a 
joint  training  standard  or  specification  for  the  encoding,  storage,  access,  and  modification  of  a 
representation  of  the  natural  and  man-made  terrain  for  virtual  and  constructive  simulation 
applications.  Terrain  database  construction  remains  a  time-consuming,  manpower-intensive 
process.  The  wide  variety  of  storage  and  (often  proprietary)  runtime  formats  makes  it  difficult  to 
transfer  terrain  data  between  simulations,  increases  support  costs,  and  limits  reuse.  Capabilities 
utilizing  proprietary  specifications  are  prone  to  being  “locked  in”  to  a  specific  technology  and/or 
vendor.  There  is  a  lack  of  an  easily  accessible  storage  capability  that  includes  metadata  and 
validation  data  for  each  product  and  incorporates  safeguards  necessary  for  the  protection  of 
classified  data  to  enable  discovery  and  reuse  by  other  users  with  similar  requirements.  All  these 
factors  contribute  to  high  terrain  data  production  costs  and  hinder  our  ability  to  easily  reuse  existing 
data  products.  The  paper  summarizes  Technical  Standards  for  Terrain  Data  Sub-Working  Group 
(TSTD  SWG)  findings  on  these  issues  and  provides  recommendations  for  stakeholder  consideration 
as  follows: 

•  Near  term  (C Y 2018) 

1.  Baseline  Requirements — Identify  and  consolidate  enterprise  environmental  data 
requirements  for  simulation  and  simulator  support  to  training,  exercise,  and  mission 
rehearsal  as  a  baseline  for  follow-on  actions. 

2.  Community  Storage — Establish  a  more  consumer-centric,  searchable,  web-enabled 
storage  of  terrain  data  to  shared  spaces  for  user  access,  encompassing  both  source 
data  and  user  community  databases  produced  for  simulation  and  simulator  use. 

•  Mid-Term  (CY2021) 

1.  Common  Library  Framework — Support  the  Simulation  Interoperability  Standards 
Organization  (SISO)  to  develop  a  common,  detailed  environmental  features 
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description  for  the  Joint  training  community,  identifying  object  instances  and  classes 
(such  as  features,  3D  objects,  and  textures)  within  the  common  library,  the  choice  of 
semantics  and  mapping  with  existing  dictionaries,  and  the  linkages/semantics 
between  instances  and  classes. 

2.  Standardize  Attributes — Establish  a  consensus  on  attributes  and  attribution  rules 
for  the  training  community. 


Long  Term  (CY2021  -  2024) 

1.  Common  Standard — Strategically  migrate  the  enterprise  toward  adoption  of  a 
common  database  standard  or  specification  where  it  will  not  adversely  affect  cost, 
schedule,  or  performance.  Ideally,  this  should  be  an  open,  national  or  international 
standard  that  can  be  used  for  both  offline  data  storage  and  as  a  runtime  database 
format.  A  phased  approach  is  recommended: 

a.  Phase  I:  Establish  a  framework  for  the  management  of  the  standard 

i.  Function  as  the  training  enterprise  body  for  the  selection  of  the 
standard. 

ii.  Manage  enterprise  changes  to  the  standard  via  the  open,  community 
based  process. 

b.  Phase  II:  Common  offline  storage  format  (by  CY2021). 

c.  Phase  III:  Transition  constructive  simulations  to  the  common  standard 
as  a  runtime  format. 

i.  New  Joint,  Service,  and  Agency  enterprise  constructive  training 
capabilities  should,  when  it  meets  requirements,  develop  to  use  a 
common  database  standard  or  specification  natively  to  accrue  the  data 
interoperability  and  processing  benefits. 

ii.  Transition  legacy  simulations  only  where  mission  needs,  cost 
effectiveness,  and  return  on  investment  warrant  conversion. 

d.  Phase  IY:  Transition  tactical  simulators  to  the  common  standard  as  a 
runtime  format. 

i.  New  Service  and  USSOCOM  enterprise  tactical  simulator  capabilities 
should,  when  it  meets  requirements,  develop  to  use  a  common 
database  standard  or  specification  natively  to  accrue  the  data 
interoperability  and  processing  benefits. 

ii.  As  with  constructive  capabilities,  transition  legacy  simulators  only 
where  mission  needs,  cost  effectiveness,  and  return  on  investment 
warrant  conversion. 

e.  Phase  Y:  Modify  the  common  standard  to  meet  unfulfilled  requirements 

-  It  is  recognized  that  a  common  standard  may  not  completely  fulfill  the 
requirements  of  every  system/platform  in  the  enterprise.  However,  enterprise 
users  should  not  reject  the  common  standard  objective  until  efforts  have 
been  attempted  to  modify  the  common  standard  to  address  any  shortfalls 
(e.g.,  multispectral  sensor  support)  that  inhibit  compatibility  with 
Service/Agency  capabilities. 
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WHITE  PAPER 
ON 

ENTERPRISE  TERRAIN  DATA  STANDARDS  FOR  JOINT  TRAINING 

1.  PURPOSE.  Provide  findings  and  recommendations  for  the  cooperative  establishment  of  a  Joint 
training  standard  or  specification  for  the  encoding,  storage,  access,  and  modification  of  a 
representation  of  the  natural  and  man-made  terrain  for  virtual  and  constructive  simulation 
applications  for  Tiers  1  through  4. 

2.  BACKGROUND.  Title  10  United  States  Code  Section  153  assigns  the  Chairman,  Joint  Chiefs 
of  Staff  (CJCS)  responsibility  for  formulating  technical  standards  for  the  Joint  training  of  the 
armed  forces.  In  support  of  this  CJCS  responsibility,  the  Joint  Training  Synthetic  Environment 
(JTSE)  Working  Group  (WG)  2016-1  of  20  January  2016  decided  to  investigate  the 
development  of  a  common  terrain  data  standard  for  the  Joint  training  enterprise  and  brief  status 
to  the  2016  World-Wide  Joint  Training  Conference  (WJTC).  The  Technical  Standards  for 
Terrain  Data  Sub-Working  Group  (TSTD  SWG)  was  subsequently  established  to  carry  out  this 
tasking,  meeting  for  the  first  time  on  4  May  2016. 

3.  DEFINITIONS.  For  the  purposes  of  this  paper,  the  following  definitions  are  provided: 

•  Accredited  standards  -  generally  have  two  important  characteristics.  They  are  developed 
and  adopted  as  standards  through  an  open  consensus  process,  under  the  guidelines  of 
national  or  international  standards  bodies  (ISO,  SISO,  IEC,  ANSI,  OGC,  etc.).  These 
procedures  ensure  that  the  concerns  of  all  interested  parties  are  heard  and  addressed.  In 
addition,  accredited  standards  tend  to  distinguish  more  clearly  the  difference  between 
requirements  (normative  elements)  that  must  be  met  to  conform  to  the  standard,  and 
descriptive  material  (informative  elements)  that  provide  additional  information,  but  do  not 
contain  requirements.  Accredited  standards  are  publicly  available  from  the  respective 
standards  bodies.1 

•  Industry  specifications  -  often  take  the  form  of  formalized  industry  practices.  These 
specifications  generally  are  developed  by  a  group  within  the  industry,  but  there  are  no 
formal  guidelines  or  procedures  that  ensure  the  work  is  open  to  any  interested  party  or  open 
to  review  and  comment  during  the  development  process.  Such  groups  are  not  bound  to 
consider  or  respond  to  comments  on  the  work.  However,  such  publications  are  generally 
publicly  available  and  can  be  referenced  in  accredited  standards.2 

•  Attribution  -  the  assignment  of  properties  to  an  object  class  or  an  object  instance 
describing  the  environment.  Attributes  can  be  included  explicitly  by  direct  attachment  to  the 
object  or  instance,  or  implicitly  by  inheriting  down  a  hierarchy  tree.  Attributes  can  be 
simply  defined  by  attribute  names  and  their  value,  or  defined  by  more  complex  schemas, 
called  attribution  rules. 

•  Authoritative  Data  Source  -  a  recognized  or  official  data  source  with  a  designated  mission 
statement,  source,  or  product  to  publish  reliable  and  accurate  data  for  subsequent  use  by 


1  Derived  from  the  Association  for  Suppliers  of  Printing,  Publishing  and  Converting  Technologies  (NPES)  Standards 
Bluebook  2013,  http://www.npes.Org/Portals/0/standards/pdf/Bluebook2013.pdf. 

2  Ibid. 

4 

UNCLASSIFIED 


UNCLASSIFIED 


customers.  An  authoritative  data  source  may  be  the  functional  combination  of  multiple 
separate  data  sources.3 * 5 

•  Dataset  -  Simply  speaking,  a  dataset  is  a  collection  of  data.  For  the  purposes  of  this  paper, 
a  dataset  will  refer  to  mid-processed  layers  of  data  that  are  correlated  and  later  compiled  to 
form  a  runtime  database  for  a  specific  application.  This  includes  data  resulting  from  the 
operations  of  refinement,  reconciliation  and  possibly  integration  of  source  data. 

•  Environmental  Database  -  refers  to  the  sets  of  geospatial  data  and  all  related  data  required 
for  modeling  and  simulation  of  entities  and  sensors.  The  production  of  an  environmental 
database  starts  from  source  data  (see  definition  below)  up  to  the  generation  of  target 
application  databases,  also  called  runtime  databases. 

•  Source  Data  -  is  used  in  internal  data  generation  processes  to  produce  one  or  more  final 
products  (usually)  specific  to  a  particular  set  of  applications,  clients,  or  systems.  Terrain 
source  data  refers  typically  to  the  raw  geospatial  data  used  to  produce  the  terrain  database. 
The  main  categories  of  source  data  are  the  imagery,  the  elevation,  cultural  and  manmade 
vector  feature  data,  and  3D  models.  The  source  data  are  stored  and  exchanged  in  source  data 
formats  widely  used  by  Geographic  Information  System  (GIS)  community. 

4.  SCOPE.  A  modeling  &  simulation  (M&S)  environmental  database  utilized  for  training  may 

include  a  myriad  of  related  data  required  for  the  replication  of  the  operational  environment  and 

the  proper  modeling  of  entities.  However,  this  paper  is  scoped  to  address  a  subset  of 

environmental  data  commonly  considered  for  a  terrain  database,  to  include: 

•  Terrain  skin. 

•  Feature  data. 

o  Hydrology  (e.g.,  rivers,  streams,  canals,  lakes,  swamps,  and  their  characteristics), 
o  Vegetation, 
o  “Cultural  overlay.” 

■  Transportation  features  (e.g.  roads,  streets,  railroads,  gas/petroleum/water 
lines,  and  electrical/communication  grids). 

■  Subterranean  features  (e.g.  tunnels,  caves,  bunkers,  and  subways). 

■  Ground  lighting. 

•  3D  models  of  buildings,  interiors  and  other  manmade  objects. 

•  Imagery. 

•  Geometric  intervisibility  (i.e.,  the  blockage  of  a  line  of  sight  (LOS)  caused  by  a  physical 
obstruction  such  as  the  terrain  skin,  3D  model,  or  feature  data  element). 

•  Spectral  characteristics  of  terrain  features/objects  to  support  sensor  visualization. 

•  Dynamic  terrain  -  aspects  supporting  terrain  and  3D  model  impacts/deformation  resulting 
from  simulation  entities  (e.g.,  bombs/shells,  vehicles,  etc.)  or  environmental  factors  (e.g., 
weather). 

•  Riverine  and  ocean  surface  and  bathymetry. 

o  Wave/swell  generation  and  refraction, 
o  Currents,  particularly  along  the  shore, 
o  Beach  and  bank  gradients  and  composition, 
o  Surf  conditions. 


3  DoDI  8320.03  of  4  November  2015,  Unique  Identification  (UID)  Standards  for  Supporting  DoD  Net-Centric 

Operations 
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o  Tides. 

o  Salinity/temperature  differences  in  the  water  column. 

o  Ocean  bottom  topography,  including  manmade  objects  (e.g.  mines  and  obstacles), 
o  Depths  and  drafts  for  waterways,  canals,  sea  lanes,  and  ports. 

Other  environmental  factors,  such  as  “human  geography”  (e.g.,  population  density,  distribution, 
demographics,  language,  ethnicity,  religion,  education,  economy,  groups,  and  other  cultural 
aspects),  atmospheric  weather  (e.g.,  temperature,  pressure,  cloud  cover,  precipitation,  day/night 
cycles,  light  conditions/shadows,  precipitation,  winds  at  varying  altitudes,  ducting  layers,  and 
conditions  affecting  visibility  such  as  fog,  smoke,  dust  clouds,  vehicle  dust,  and  haze),  and 
space  “weather”  (e.g.,  scintillation  and  ionospheric  refraction,  solar  winds  and  flares,  electron 
density  profile/total  electron  count,  and  radiation)  while  important,  are  not  included  within  the 
scope  of  this  paper.  These  factors  can  be  addressed  later  as  a  separate  issue  or  as  an  addendum 
to  this  white  paper. 

5.  DISCUSSION.  The  Joint  training  community  has  faced  a  number  of  historical  challenges  to 
terrain  generation,  including: 

•  Duplicate  and  poorly  correlated  source  data. 

•  Dependence  on  subject  matter  experts  (SMEs)  to  create  and  modify  terrain  data  and  the 
need  to  rapidly  change  databases  during  the  event  planning  cycle  to  accommodate 
emerging  training  requirements. 

•  Most  simulations  and  simulators  utilize  application-specific,  proprietary  runtime 
formats.  The  wide  variety  of  runtime  formats  makes  it  difficult  to  transfer  terrain  data 
between  simulations,  increasing  support  costs  and  hindering  reuse.4 

•  Lack  of  a  web-based  repository  of  authoritative  training  data  for  users  to  share  and  reuse 
existing  terrain  datasets  and  databases,  to  include  a  cross-community  configuration 
management  (CM)  structure  to  inventory  holdings. 

•  Requirements  for  short  terrain  development  timelines  to  support  mission  rehearsal. 

•  Difficulty  in  sharing  terrain  data  with  Coalition  Allies,  who  more  commonly  utilize 
open,  international  standards.  This  is  compounded  by  policy  issues  that  restrict  release 
of  classified  source  data  or  limited  distribution  (LIMDIS)  material. 

The  primary  purpose  of  the  TSTD  SWG  is  to  study  these  problems  across  the  Joint  training 
community  and  identify  requirements  and  possible  common  solutions  for  the  encoding,  storage, 
access,  and  modification  of  terrain  databases  for  simulation  applications. 

a.  The  Argument  for  Adopting  a  Common  Enterprise  Terrain  Database  Standard  or 
Specification.  Terrain  databases  are  created  through  a  costly  and  time-consuming  authoring 
process  resulting  in  very  large  platform-dependent  databases  that  often  support  single 
applications.  During  this  production  process,  data  from  various  sources  and  formats  is 
collected,  managed,  validated,  harmonized,  referenced,  attributed,  decimated  (sometimes 
intensified),  and  then  published  to  the  simulation  application(s).  Conversion  of  one  system's 
data  to  another  format  is  based  upon  rigidly  defined  data  format  specifications  for  both  the 


4  While  databases  used  for  daily  simulator  training  events  at  the  Tier  3  and  4  levels  are  reused  on  a  repeated  basis, 
constructive  terrain  databases  at  the  Tier  1  and  2  levels  are  commonly  built  for  a  single  purpose  and  infrequently  reused. 
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source  and  target  system.  Differing  proprietary  data  formats  require  the  development  of  a 
customized  data  converter  software  application  to  accomplish  each  conversion.  These 
point-to-point  solutions  are  expensive,  time  consuming,  and  often  unreliable.  Specific  target 
system  implementation  needs  usually  require  the  converted  data  undergo  several  additional 
conversions  before  a  useable  runtime  format  is  obtained.  Each  conversion  adds  to  the  risk 
of  data  loss  or  corruption.  Additionally,  the  number  of  unique  conversions  increases 
geometrically  with  the  number  of  sources  involved.  A  study  conducted  by  the  US  Joint 
Training,  Integration,  and  Evaluation  Center  (JTIEC)  in  2010  identified  93  different  types  of 
geospatial  data5 * 7  used  in  Live,  Virtual,  &  Constructive  (LVC)  simulations  with  10  different 
active  standards  and  mediation  formats  in  use  by  the  M&S  community  (Morse,  K.,  et  al., 
2010).  Development  and  maintenance  of  these  conversion  software  modules  can  quickly 
become  cost-prohibitive. 

There  are  a  number  of  advantages  and  disadvantages  to  consider  in  maximizing  adoption  of 
a  common  enterprise  terrain  database  standard  or  specification: 

Advantages 

•  Improved  ease  of  constructing  and  correlating  synthetic  environments  and  making  rapid 
updates/changes  to  the  synthetic  environment  databases  supporting  training  and  mission 
rehearsal  requirements. 

•  Improved  data  interoperability  between  federates  and/or  services  within  complex 
training  systems.  Databases  conforming  to  the  standard  or  specification  can  be  more 
easily  reused  as  well  as  interchanged  and  shared  between  end  users. 

•  Reduced  data  configuration  management  workload. 

•  Reduced  costs  and  shortened  production  timeline  for  database  development  by 
eliminating  redundant  implementation  work.  If  the  synthetic  environment  database  can 
be  shared  in  an  enterprise  distributive  mission  training/operation  event  and  also  used  as 
both  a  storage  format  and  a  runtime  format,  time  and  labor  costs  are  essentially 
eliminated  for  off-line  data  compilation  into  proprietary  simulation  client  data  formats 
(assumes  client  conversion  to  use  databases  structured  in  accordance  with  the  standard 
or  specification). 

Disadvantages 

•  Converting  existing  data  to  the  new  standard  or  specification  may  result  in  data 
corruption,  missing  data  or  data  loss. 

•  There  may  be  technical  compatibility  issues  that  make  transition  infeasible  or 
inordinately  time  consuming  and  costly  to  implement. 

•  Transition  to  a  new  standard  or  specification  may  pose  possible  risk  of  extended 
downtime  and  operational  impact  to  the  organization.  This  is  ameliorated  somewhat,  in 


5  Of  the  93  data  formats,  80  were  actively  maintained.  Thirteen  of  those  formats  were  not  strictly  data  storage  formats, 
but  were  included  as  they  were  data  dictionaries  or  conceptual  models  without  which  several  important  storage  formats 

could  not  be  implemented.  Of  the  remaining  entries  on  the  list,  four  were  GIS  extensions  to  major  relational  databases, 
71  were  unique  storage  formats,  and  five  were  Service-  or  Department-specific  “universal”  geospatial  databases.  Ten  of 
the  storage  formats  and  10  of  the  conceptual  models  were  identified  as  mediation  formats. 
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that  software  programs  usually  have  separate  development  and  production  (operational) 
baselines;  however,  the  transition  may  result  in  a  longer  than  usual  development  period. 

•  Development  costs  associated  with  adapting  training  simulations,  simulators  and  tools  to 
use  databases  constructed  in  accordance  with  the  new  standard  or  specification. 

It  could  be  argued  that  future  sensors  may  require  additional  spectrums  of  material 
reflectivity  data  that  may  not  be  supported  by  the  common  format;  or  that  limitations  of  data 
formats,  data  structures,  and  available  product  choices  may  impede  innovation  for  future 
image-generation  technology  that  could  improve  the  quality  of  training.  However,  these  are 
considered  neutral  in  impact,  since  these  challenges  are  inherent  to  any  standard  or 
specification  selected,  common  or  otherwise.  Use  of  open,  consensus-based  standards  can 
ameliorate  these  factors  by  providing  the  flexibility  to  adapt  and  evolve  the  standard  to  meet 
community  needs. 

Given  these  circumstances,  there  are  two  approaches  that  could  be  followed  in  establishing  a 
common  enterprise  database  standard  or  specification: 

(1)  Establish  a  common  standard  or  specification  for  off-line  data  storage  only  -  This 
approach  would  provide  the  benefits  of  data  interchange  and  reuse,  but  would  still 
require  off-line  recompiling  of  the  data  into  each  client  application’s  runtime  format. 

(2)  Establish  a  common  standard  or  specification  for  both  off-line  data  storage  and  runtime 
applications  -  This  approach  gains  additional  benefits  in  eliminating  costs  associated 
with  recompiling  into  runtime  formats.  However,  in  today’s  constrained  fiscal 
environment,  any  decision  to  move  to  a  dual-use  open,  common  terrain  database 
standard  or  specification  for  the  training  enterprise  must  weigh  the  operational 
advantages  of  doing  so  against  the  opportunity  costs  and  operational  impacts.  The 
circumstances  for  each  simulation/simulator  system  will  vary  and  must  be  individually 
assessed. 

b.  Foundational  attributes:  The  TSTD  SWG  established  a  set  of  criteria  that  would  be  used 
in  the  comparison  of  candidate  specifications  as  follows. 

(1)  Utilize  open,  evolving,  publicly-available,  published  standards  that  are  platform 
independent.  (Note  l)6 

Reasoning:  Adoption  of  an  open,  national/intemational  standard  would  provide  end 
users  direct  access  to  the  specification  and  allow  its  further  development  through  an 
open,  participatory  process.  If  open  standards  are  followed,  applications  are  easier  to 
port  from  one  platform  to  another  since  the  technical  implementation  follows  known 
guidelines  and  rules,  and  the  interfaces,  both  internal  and  external,  are  known.  As  a 
result,  there  will  be  improved  data  interchange  and  exchange.  If  guidelines  are  followed, 
open  standards  offer  better  protection  of  the  data  files  created  by  an  application  against 
obsolescence  of  the  application.  This  is  especially  beneficial  with  respect  to 
organizations  that  possess  huge  amounts  of  data  stored  electronically.  Open  standards 
are  less  prone  to  being  “locked  in”  to  a  specific  technology  and/or  vendor.  While 
adoption  of  open,  publicly-available  standards  is  not  mandatory,  it  is  highly  desirable 


6  The  “Note”  annotations  pertain  to  notes  in  Attachment  1  at  the  back  of  the  paper  that  trace  these  foundational 
attributes  to  available  Joint  or  Service  requirements. 
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since  other  specifications  and  non-accredited  standards  that  are  not  open  tend  to  fulfill 
only  specific  requirements  of  specific  users  and  do  not  benefit  from  community  input. 
This  limits  wide  adoption  and  thus  the  underlying  value  of  an  open  database  standard 
and  the  notion  of  reusability.  The  use  of  open  international  standards  is  also  more 
amenable  to  use  by  our  foreign  partners. 

(2)  Support  runtime  applications  and  source  data  storage.  (Note  2) 

Reasoning:  Such  a  dual-use  standard  or  specification  may  reduce  the  time  and  labor 
costs  required  for  simulation  terrain  production,  since  there  is  no  need  to  recompile  into 
a  specific  simulation  runtime  format  (assumes  client  conversion  to  use  databases 
constructed  in  accordance  with  the  standard  or  specification).  It  reduces  data  storage 
requirements,  reduces  the  loss  of  correlation  resulting  from  the  compilation  process, 
avoids  complexity  in  configuration  management,  and  yields  a  more  efficient  update 
process.  The  shorter  production  to  runtime  time  constraints  are  of  particular  value  to 
organizations  with  short-cycle  mission  rehearsal  needs  (e.g.  Special  Operations  Forces). 

(3)  Allow  rapid  data  access  for  concurrent  multiple  simulations  and  services.  (Note  3) 
Reasoning:  Standard  or  specification  storage  structure  is  optimized  for 
simulation/simulator/service  client  runtime  performance  and  promotes  efficient,  real¬ 
time,  simultaneous  data  access  by  all  participating  client  devices.  This  optimized 
storage  structure  also  permits  flexible  and  efficient  updates  due  to  the  different  levels  of 
granularity  with  which  the  information  can  be  stored  or  retrieved. 

(4)  Allow  simulation  clients  to  modify  the  terrain  data  store  while  the  simulation  is 
running  during  an  exercise/training  event.  (Note  4) 

Reasoning:  Supports  the  user’s  ability  to  quickly  modify  the  terrain  and  3D  models 
during  runtime  to  correct  discrepancies  found  in  testing  or  accommodate  the 
accomplishment  of  training  objectives  during  an  event.  The  use  of  such  a  dynamic 
editing  capability  would  necessarily  be  controlled  by  a  training  event  authority  (e.g. 
Exercise  Director)  to  avoid  corruption  of  the  database  or  disruption  of  the  event. 

(5)  Support  dynamic  terrain  and  revision  history  (i.e.  allow  deformation  of  the  terrain 
and  3D  objects).  (Note  5) 

Reasoning:  Necessary  for  accurate  representation  of  the  effects  of  modeled  actions  (e.g. 
weapon  effects,  weather  effects,  and  actions  of  modeled  entities)  on  the  terrain  (e.g. 
rubbled  buildings,  poor  traffic  ability  due  to  precipitation,  and  digging  of  tank  trenches). 

(6)  Support  procedural  geometry  (e.g.,  procedurally  generate  ground  textures  from 
raster  material  layers).  (Note  6) 

Reasoning:  Ability  to  support  the  generation  of  realistic,  highly-detailed  objects  and 
textures  enables  the  terrain  builder  to  automatically  create  large  amounts  of  content  with 
smaller  file  sizes  and  reduced  labor. 

(7)  Support  global  coverage  with  multiple  levels  and  layers  of  detail  (i.e.  capable  of 
storing  very  high  resolution  data).  (Note  7) 

Reasoning:  Necessary  for  high  spatial  resolution  and  scalability,  a  terrain  database  that 
can  provide  multiple  levels  of  detail  in  a  hierarchical  structure  provides  an  efficient 
means  to  organize  synthetic  terrain  data  and  allow  access  to  the  information  at  the 
required  detail  level.  Multiple  layers  (e.g.  vectoring  data,  material  coding,  and  light 
sources)  are  necessary  to  support  sensors  and  other  simulated  functions. 

Data  production  standards  or  specifications:  The  TSTD  SWG  investigated  the  following 

initiatives  associated  with  the  various  component  terrain  generation  capabilities: 
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(1)  Master  Database  (MDB)  -  Developed  and  used  specifically  by  the  U.S.  Army  PEO- 
STRI  Synthetic  Environment  Core  (SE  Core)  program.  MDB  defines  the  central 
repository  for  the  creation  of  correlated  databases  used  to  train,  mission  plan,  or  mission 
rehearsal  in  the  Live,  Virtual,  or  Constructive  (LVC)  domains.  MDB  supports  the 
ability  to  store  common  standard  source  data  that  is  configuration  managed,  quality 
assured,  and  correlated  in  a  format  usable  by  multiple  vendors  and  products. 

(2)  NAVAIR  Portable  Source  Initiative  (NPSI)  -  Developed  by  US  Naval  Air  Systems 
Command  (NAVAIR)  and  used  specifically  by  the  U.S.  Navy.  NPSI  provides  database 
reuse  across  Type/Model/Series  platforms  to  lower  the  life  cycle  cost  of  out-the- window 
visual  terrain,  3D  models,  and  sensor  databases,  and  adds  dataset  archive  capability  and 
short-notice  distribution  services.  The  metadata  and  metadata  architectures  are  used  to 
facilitate  data  discovery,  data  understanding,  and  effective  data  distribution.  The 
metadata  is  also  employed  for  NPSI  dataset  archiving  and  distribution. 

(3)  Air  Force  Common  Dataset  (AFCD)  -  Derived  from  the  NPSI  specification  and  used 
specifically  by  the  U.S.  Air  Force.  AFCD  was  developed  to  help  improve  database 
cost/schedule/performance  and  reduce  correlation  differences  among  Air  Force 
simulation  programs.  AFCD  references  common  commercial  formats  developed  and 
used  by  industry  and  adopted  by  the  Government.  This  approach  does  not  favor  any 
single  source  supplier  of  databases  or  database  toolsets;  and  focuses  on  commercially 
defined  interfaces  in  interim  format  files,  rather  than  mandating  the  runtime  product.7 

(4)  Common  Database  (CDB)  -  Used  by  U.S.  Special  Operations  Command 
(USSOCOM),  U.S.  Marine  Corps,  Joint  Staff  J7,  the  National  Geospatial  Intelligence 
Agency  (NGA)  Foundation  GEOINT  3D  initiative,  and  13  foreign  partners.  CDB  is  an 
Open  Geospatial  Consortium  (OGC)  Standard  (CDB  1.0)  adopted  on  September  23, 
2016.  The  CDB  synthetic  environment  represents  the  natural  environment  including 
external  features  such  as  man-made  structures  and  systems.  It  encompasses  terrain  relief, 
terrain  imagery,  three-dimensional  (3D)  models  of  natural  and  man-made  cultural 
features,  3D  models  of  dynamic  vehicles,  the  ocean  surface,  and  the  ocean  bottom, 
including  natural  and  man-made  features  on  the  ocean  floor. 

d.  Initial  Findings 

(1)  Data  production  for  the  training/exercise  events:  High  level  processes  used  across 
the  community  in  building  terrain  databases  are  similar  with  subtle  differences  between 
components  in  the  following  steps: 

•  Identify  terrain  data  requirements/sources  -  This  requires  some  preliminary 
actions  by  the  event  owner  to  define  the  scenario  parameters/scope  and  the  required 
data  elements  for  the  baseline,  to  include  the  simulations/federation  to  be  used.8 * 10 
This  enables  identification  of  terrain  data  requirements  and  determination  of  desired 
data  sources  for  query. 


7  AFCD  and  NPSI  use  the  notion  of  dataset  to  designate  a  set  of  environmental  data  used  and/or  built  by  database 
producers  during  their  database  generation  process  excluding  the  target  application  level  data  that  they  call  a  (runtime) 
database.  This  includes  data  resulting  from  the  operations  of  refinement,  reconciliation  and  possibly  integration  of 
source  data  (RIEDP  Study  Group  Final  Report,  8  October  2012). 

8  This  example  is  typical  of  a  Joint  training  event.  Tier  3  and  4  simulator  training  define  required  databases/terrain  off 

daily  or  deployment  training  needs,  OPLAN  requirements,  etc.  and  are  not  usually  driven  by  a  larger,  specific  event. 
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•  Gather  required  data  -  These  source  data  products  come  largely  from  (but  are  not 
limited  to)  government  sources  like  the  NGA  and  the  National  Reconnaissance 
Office  (NRO).  Based  on  defined  requirements,  catalogs  are  searched  and  existing 
datasets  and  databases  meeting  criteria  are  downloaded.  Where  authoritative  data 
sources  are  not  available,  terrain  data  products  are  generated  from  imagery,  field 
collection,  databases,  etc.  as  required. 

•  Process  and  refine  the  data  -  Using  geospatial  software,  correct  errors;  add  detail; 
correlate  features,  elevation,  and  imagery  with  other  data  in  the  baseline;  and  add 
required  3D  models.  It  was  generally  agreed  that  the  process  and  refinement  stage 
constituted  the  majority  of  the  time  and  labor  costs  involved  in  producing  a  terrain 
database.  Conducting  error  correction  and  correlation  at  the  authoritative  data  source 
(e.g.  NGA,  NRO,  etc.)  would  greatly  alleviate  the  burden  on  Joint  and  Service 
trainers  and  other  communities.  The  ability  to  get  geo-referenced  and  orthorectified 
imagery  (along  with  color  correction  and  seasonal  matching)  from  authoritative 
sources  would  be  a  great  gain  for  all  using  communities. 

•  Post-Process  the  data  -  The  structure  and  level  of  detail  for  the  dataset  is 
established  and  compiled  to  form  the  required  runtime  database  for  the  simulation 
application(s)  to  be  used.  This  step  also  involves  exporting  the  data  as  required  and 
saving  to  the  appropriate  repository. 

•  Test  -  The  database  is  loaded  into  the  simulation/simulator  and  tested  in  runtime. 
Problems  discovered  during  testing  are  corrected  in  the  baseline  and  saved. 

(2)  Standard  or  specification  analysis:  The  Comparison  Matrix  in  Attachment  2  provides 

the  summary  analysis  between  the  four  standard/specifications,  which  is  summarized 

below: 

•  The  standard/specifications  vary  in  their  scope,  breadth,  and  depth;  but  fulfill  the 
data  production  and/or  data  format  requirements  of  their  respective  users.  However, 
they  are  too  diverse  to  support  a  common  enterprise  data  repository  without  the 
addition  of  format  translation  capabilities. 

•  The  standard/specifications  use  established  geospatial  source  data  and  industry 
standards.  Common  among  the  initiatives  were  TIFF,  GeoTIFF,  OpenFlight, 
Shapefile,  DTED,  JPEG,  and  JPEG  2000.  Note:  CDB  can  read  the  DTED,  but  saves 
the  data  in  GeoTIFF  format. 

•  Although  there  is  a  great  deal  of  similarity  among  the  standard/specifications  with 
regard  to  the  data  standard  formats  used,  shapefile  attributions  differ  and  present  an 
obstacle  in  harmonizing  databases.  Shapefile  attributions  are  user-defined  and  not 
constrained  by  the  format,  which  creates  complexity  and  increases  the  difficulty  in 
mapping  data  models. 

•  CDB  is  the  only  one  of  the  four  that  has  been  vetted  by  an  international  standards 
body  (OGC)  and  has  been  approved  as  an  open,  accredited  standard. 

•  Most  database  formats  serve  only  as  a  storage  format  and  require  a  full  off-line  re¬ 
compilation  of  the  database  into  a  (usually  proprietary)  simulation  runtime  format. 
The  CDB  standard  is  unique  in  that  geospatial  data  structured  in  accordance  with  the 
standard  can  serve  as  both  an  offline  storage  archive  and  as  a  runtime  format  for 
simulations/simulators  that  can  directly  publish  CDB. 
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•  All  four  use  the  WGS-84  Earth  Model  as  a  reference  coordinate  system,  which  has 
gained  universal  acceptance  within  the  GIS  community  as  the  preferred  method  for 
defining  where  objects  exist  on  the  earth. 

Reuse  and  Interoperation  of  Environmental  Data  &  Processes  (RIEDP)  Study:  The 

TSTD  SWG  reviewed  the  findings  from  the  Simulation  Interoperability  Standards 
Organization  (SISO)  RIEDP  Final  Report  of  October  2012.  The  RIEDP  Study  Group 
resulted  from  the  Fall  2009  SISO  Special  Workshop  on  the  Reuse  of  Environment  Data  for 
Simulation.  The  goal  of  the  group  was  to  harmonize  source  data  and  production  processes 
for  environmental  database  generation,  capitalization,  and  reuse;  with  a  focus  on  the  needs 
of  the  aircrew  training  and  mission  rehearsal  communities.  Like  the  TSTD  SWG,  the  Study 
Group  reviewed  the  CDB,  MDB,  NPSI,  and  AFCD  initiatives;  as  well  as  the  French  Air 
Force  community  Sogitec/Thales,  UK  MoD  and  German  Rheinmetall  initiatives.  As  with 
the  TSTD  SWG,  the  RIEDP  Study  found  that  the  initiatives: 

•  Used  the  same  core  of  geospatial  source  data  formats. 

•  Used  the  same  high  level  database  generation  process  flow  with  the  same  stages. 

•  Showed  similarities  between  initiative  data  models,  which  was  expected  given  heavy 
reliance  on  commercial-off-the-shelf  (COTS)  products  and  de-facto  or  standard  formats. 

•  However,  data  models  diverge  along  the  stages  of  each  process,  particularly  in  the  use  of 
feature  dictionaries,  attribute  definitions,  and  the  attribution  rules.  This  divergence 
complicates  data  reuse  between  initiatives,  and  even  impedes  it,  if  the  data  models 
cannot  be  “interfaced.” 

Each  of  the  initiatives  were  assessed  against  the  Generation  Process  Model  revealing  the 
following  areas  of  convergence: 

•  Source  data  formats:  All  Initiatives  used  Geospatial  Information  System  (GIS) 
technology  and  associated  formats;  however,  using  the  same  source  data  formats  may 
not  be  sufficient  to  allow  a  full  convergence. 

o  Raster  formats  (e.g.,  DTED,  GeoTiff,  and  JPEG2K)  can  be  good  enough  for 
convergence  and  conversion  tools  exist  between  all  these  formats, 
o  However,  Shapefiles  format  with  its  user-defined  attribution  schema  can  lead  to 
divergence. 

•  Layers:  Also  derived  from  the  GIS  source  data  formats,  the  basic  layers  (elevation, 
features,  texture,  3D  objects)  are  commonly  shared,  with  similar  formats  amongst  the 
initiatives;  but  layer  content,  detail,  and  resolution  may  be  different  for  specific  purposes 
and  must  be  looked  at  closely. 

•  Tiles:  Source  data  are  often  delivered  by  producers  using  regular  tiles.  Additionally,  the 
database  generation  process  can  often  use  parallel  processing,  which  also  leads  to  cutting 
the  domain  into  regular  tiles.  Similarly,  preparing  the  data  for  use  during  runtime  may 
require  the  use  of  tiles. 

o  However,  there  is  a  great  variety  of  requirements  among  the  initiatives,  from  the 
“no  specific  tile  size”  (AFCD  approach)  to  the  CDB  fully  defined  tile  schema. 
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o  Tiles  can  be  adjusted  at  any  time  using  the  GIS  tools  capabilities;  so  this  is  not  a 
main  technical  issue,  but  does  have  a  cost. 

The  RIEDP  Study  Group  found  the  following  areas  of  divergence  among  the  initiatives: 

•  Internal  format:  Pertains  to  the  aggregation  of  the  data  from  the  layers  to  produce  a 
desired  “integrated  database.”  This  primarily  involves  the  definition  of  a  library  of  object 
classes  and  the  linkage  of  these  with  the  object  instances. 

o  Depending  on  the  initiative,  the  notion  of  “integrated  database”  may  or  may  not 
make  sense.  For  instance,  AFCD’s  scope  did  not  cover  this  notion,  leaving  it  to 
the  responsibility  of  the  simulation  database  provider  (who  receives  the  AFCD 
data). 

o  At  the  opposite  end  of  the  spectrum,  MDB,  CDB,  and  French  Air  Force 
initiatives  had  integrated  databases,  but  with  significant  differences  in  their 
internal  formats,  reducing  database  reusability  and  impacting  the  correlation  of 
the  database  generation  results  at  the  target  application  level. 

•  Dictionary:  The  terms,  labels,  and  concepts  that  allow  the  data  providers  to  designate 
and/or  describe  the  features  and  components  of  the  environment  and  their  attributes. 

The  initiatives  do  not  use  the  same  dictionaries,  often  using  terms  or  concepts  that  are 
not  covered  in  the  various  standard  dictionaries.  This  results  in  each  initiative  defining  a 
specific  dictionary  for  their  own  purposes. 

•  Attribution:  Environmental  data  is  often  generally  derived  from  GIS  data,  with  specific 
simulation  requirements  integrated  via  a  set  of  attributes  associated  with  various 
features.  The  use  of  Shapefile  format  with  its  user-defined  attribution  schema  can  lead  to 
divergence.  While  mapping  can  be  used  to  allow  unambiguous  exchange  of 
environmental  data  between  initiatives  using  different  dictionaries,  this  mapping 
principle  may  not  suffice  with  regards  to  attribution  rules  associated  to  specific  modeling 
of  the  environment,  as  the  complexity  from  semantics  remains.  For  example,  the  RIEDP 
Study  found  that  an  attribute  may: 

o  Be  relevant  to  different  entity  types  (for  instance  point,  linear  or  areal  features) 
and/or; 

o  Be  used  at  different  abstraction  levels  of  the  data  model  (for  instance  Feature 
Class  level  or  Feature  Instance  level)  and/or; 

o  Have  different  ranges  of  values  and/or; 

o  Refer  to  a  sub-model,  more  or  less  complex,  allowing  flexibility  in  the  extension 
of  the  data  model. 

The  notion  of  attribution  involves  the  concept  of  a  data  model.  Comparing  the  data 
models  adopted  by  each  initiative,  the  attributes  and  attribution  rules  (governing  how 
such  features  and  components  may  be  attributed)  were  different  among  the  initiatives 
and  were  the  most  significant  divergence  area. 
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The  RIEDP  Study  Group  determined  that  attribution  issues  and  dictionary  were  the  most 
important  sources  of  discrepancies  between  initiatives  and  the  most  likely  areas  to  focus 
standardization  efforts. 

f.  What  about  Synthetic  Environment  Data  Representation  and  Interchange 
Specification  (SEDRIS)?  A  primary  goal  of  the  SEDRIS  International  Standards 
Organization  (ISO)  standard  is  to  enable  reuse  and  sharing  of  data  and  related  tools  between 
authoring  and  application  systems,  thereby  eliminating  the  need  to  re-create  each  database 
from  scratch.  SEDRIS  facilitates  interoperability  among  heterogeneous  information 
technology  applications  by  providing  complete,  unambiguous,  and  non-proprietary 
interchange  of  environmental  data  (e.g.,  terrain,  ocean,  air  and  space).  The  SEDRIS  data 
interchange  specification  supports  the  pre-runtime  distribution  of  source  data,  three- 
dimensional  models,  and  integrated  databases  that  describe  the  physical  environment  for 
both  simulation  and  operational  use.  SEDRIS  accomplishes  this  in  two  ways.  First,  it  offers 
a  Data  Representation  Model,  augmented  with  an  Environmental  Data  Coding  Specification 
(EDCS)  and  Spatial  Reference  Model  (SRM)  to  provide  clear  and  unambiguous  articulation 
of  environmental  data.  Second,  it  provides  an  Application  Program  Interface  (API)  and 
associated  tools  and  utilities  to  create  and  convert  standard  geospatial  data  into  a  defined 
SEDRIS  Transmittal  Format  (STF)  to  allow  interchange  of  data  that  can  be  described  using 
the  Data  Representation  Model.9  While  SEDRIS  has  utility  in  data  sharing,  it  has  not  gained 
significant  traction  in  the  Joint  training  community.  Although  the  STF  format  uses  a 
common  definition  for  environmental  data  attributes  and  interchange,  it  is  neither  a  data 
repository  nor  a  runtime  format.  Much  like  other  static  formats,  changes  to  the  original 
source  data  results  in  a  recompilation  to  the  STF. 

6.  GEOSPATIAL  REPOSITORY  AND  DATA  (GRiD)  MANAGEMENT  SYSTEM.  GRiD 
Management  System  is  a  NGA  advanced  enterprise-level  database  for  point  clouds,  elevation 
models  and  high-resolution  3D  content  developed  in  partnership  with  the  US  Army  Corps  of 
Engineers  (US  ACE)  Cold  Regions  Research  and  Engineering  Laboratory  (CRREL).  GRiD  has 
begun  the  transition  to  serve  as  the  Source  Elevation  Service  portal  for  the  office  of  Geomatics 
within  NGA,  in  addition  to  remaining  the  point  cloud  repository  for  the  National  System  for 
Geospatial-intelligence  (NSG).  GRiD  is  designed  to  store,  process,  visualize  and  disseminate  a 
variety  of  geospatial  datasets,  such  as  3D  point  cloud  data  (e.g.  Light  Detection  and  Ranging 
(LiDAR))  and  associated  co-collected  2D  geospatial  products  (e.g.  digital  elevation  model 
(DEM),  Electro-Optical  (EO)  imagery,  etc.).  The  GRiD  program  is  regularly  making  software 
and  operational  modifications  and  enhancements  in  order  to  improve  the  user  experience,  such 
as  integrating  high  value  new  and  existing  GEOINT  data  into  GRiD.  GRiD  is  becoming  the  3D 
high  resolution  portal  for  NGA,  the  Services,  and  NSG  partners.  The  GRiD  team  has  finished 
migrating  both  the  SIPR  and  the  JWICS  GRiD  systems  to  CONUS.  The  JWICS  GRiD  system 
is  operational  on  the  Commercial  Cloud  Service  (C2S).  Users  should  note  that  the  data 
migration  of  over  300TBs  of  LiDAR  point  clouds,  imager  and  elevation  models  is  on-going 
until  data  holdings  are  equalized  across  all  three  systems  (as  appropriate). 

Now  that  the  Office  of  Geomatics  is  within  the  Source  Portfolio,  Foundation  GEOINT  Group 
within  NGA  has  formally  picked  up  GRiD  as  a  production  solution  for  elevation  and  3D  surface 
content  for  NGA,  the  future  of  GRiD  is  stable  and  no  longer  in  danger  of  year-to-year  funding 


9  SEDRIS  Technologies  web  site  (www.sedris.org). 
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paradigms.  By  the  close  of  2017,  GRiD  will  be  serving  NGA  Foundation  GEOINT  DEMs, 
Geodetic  Survey  points,  LiDAR  collections  (ground  and  air-based),  EO  point  clouds,  DEMs 
produced  by  EO  collections,  as  well  as  point  clouds  produced  from  Unmanned  Aerial  Vehicles. 
By  the  close  of  2018,  GRiD  will  be  producing  and  serving  high  resolution  3D  synthetic  modeled 
content,  including  roads,  trees,  buildings  and  more  as  it  undergoes  a  second  transformation  to 
become  the  service  solution  for  Foundation  GEOINT  3D  (FG3D).  The  FG3D  initiative  will 
export  data  products  in  CDB  format.  The  figure  below  illustrates  the  concept. 


Foundation  GEOINT  3D 


OGC  Services 
(CDB  Schema) 

I  i 

D1...LOD2...LOD  32 


GRID 

•  Comprehensive  3D  Surface  data 

•  Finished  spec-produced  elevation  data  (DTED, 
SRTM,  HRTF,  TRFx) 

•  unfinished,  auto  generated  elevation  data 
(level  3, 4,  S) 

•  Point  Clouds 

•  EO,  RADAR,  Ground  and  Air-based  LIDAR 


IIM, 


Our  Vision:  The  World  in  3D 


Supporting:  3D-Spaliol 
immersion. 

Services  and  Availability 

•  On-Demand  when  the  customer  needs  itl 

•  Streaming  -  OGC  services  live  to  your  console. 

•  Cloud-based  secure  access 

•  Available  on  all  three  security  domains 
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7.  A  CASE  FOR  CDB  AS  A  JOINT  TRAINING  ENTERPRISE  STANDARD.  Selection  of  a 
common  database  standard  or  specification  should  be  a  consensus-based  enterprise  decision.  As 
a  potential  candidate,  the  CDB  standard  offers  a  number  of  attributes  favorable  to  adoption, 
since  it: 


•  Has  become  an  open  OGC  international  standard. 

•  Serves  as  both  a  storage  medium  as  well  as  a  non-proprietary  runtime  format. 

•  Does  not  explicitly  mandate  the  use  of  specific  computer  platforms  and  system  software;  as 
a  result  it  can  be  implemented  on  existing  platforms. 

•  Has  an  internal  data  representation  model  based  on  open  industry  standard  native  source 
data  formats,  including  TIFF,  Geo-TIFF,  OpenFlight,  Shapefile,  and  JPEG/JPEG  2000  -  all 
of  which  are  used  by  the  enterprise. 

•  Defines  content  necessary  to  support  simulator  client-devices;  including  visual  systems, 
sensors  such  as  forward  looking  infrared  (FLIR)  and  night  vision  goggles  (NVG),  radar/laser 
reflectivity,  computer-generated  forces,  and  weather  simulation. 

•  Follows  DIS  entity  enumeration  conventions,  permitting  CDB-compliant  moving  models  to 
seamlessly  integrate  with  a  DIS-compliant  simulator. 

•  Is  scalable  and  can  be  built  to  a  size  or  a  density  that  far  exceeds  the  capability  of  current 
and  future  client  devices.  CDB  can  be  scaled  to  take  advantage  of  future 
simulation/simulator  technological  improvements. 
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•  Is  structured  with  multiple  Levels-of-Detail  (up  to  34)  and  tiled  in  such  a  manner  as  to 
promote  efficient  storage,  access,  and  transportation.  Tiles  /  features  are  located  /  oriented 
using  WGS-84  coordinates. 

•  Supports  dynamic  terrain  and  procedural  geometry. 

•  Provides  users  the  ability  to  store  different  versions  of  a  CDB  database  in  multiple  locations 
(e.g.  classified  imagery  can  be  placed  in  a  separate  version  and  stored  using  appropriate 
security  protocols  as  required  by  data  sensitivity. 

•  Is  already  used  by  3  of  the  6  owners  of  simulation  capabilities  in  the  enterprise. 

•  Is  used  in  off-line  database  creation  capacities  for  legacy  simulators  without  runtime 
publishing  capability,  including  converting  NPSI  datasets  to  CDB  format. 

•  Is  being  evaluated  within  the  special  operations  community  in  the  following  simulators  for 
possible  use  of  CDB  runtime  publishing: 

o  160th  Special  Operations  Aviation  Regiment  (Airborne)  (SOAR(A)):  MH-60,  MH- 
47  and  MH-60M 

o  AFSOC:  AC-130U,  MC-130H,  AC-130W,  CV-22,  and  U-28 

•  Is  used  by  NGA’s  Foundation  GEOINT  3D  initiative  as  an  export  format. 

•  Is  used  by  UK  MoD  (100+  terabytes  of  CDB  data);  and  12  other  countries  have  used  the 
specification  to  support  multiple  simulator  platforms. 

In  the  interim,  as  a  potential  near  term  action,  increased  community  participation  in  the  open, 
consensus-based  CDB  standard  development  process  can  address  any  shortfalls  in  the 
specification  (e.g.,  multispectral  sensor  support)  that  inhibit  compatibility  with  Service/Agency 
capabilities. 

8.  RECOMMENDATIONS.  The  TSTD  SWG  recommends  the  following  mitigating  actions 
toward  greater  harmonization  of  terrain  databases  and  their  associated  creation  processes  within 
the  training  community.  These  recommendations  in  many  ways  mirror  those  of  the  RIEDP 
Study  Group’s  from  three  years  ago. 

a.  Near  term  actions  (CY2018): 

(1)  Identify  and  consolidate  enterprise  environmental  data  requirements  as  a  baseline 
for  follow-on  actions.  The  effort  should  comprehensively  identify  all  aspects  of 
environmental  data  needed  for  simulation  and  simulator  support  to  training,  exercise, 
and  mission  rehearsal  including,  but  not  limited  to,  training  tiers,  missions,  platforms, 
weapons,  and  sensors. 

(2)  Establish  a  more  consumer-centric,  web-enabled  storage  of  terrain  data  to  shared 
spaces  for  user  access.  Data  would  be  fully  visible,  searchable,  accessible  and 
understandable,  except  when  limited  by  security,  policy,  or  regulations.  This  would 
require  metadata  “tagging”  of  all  data  (intelligence,  non-intelligence,  raw  and  processed) 
to  enable  authorized  discovery  by  known  and  unanticipated  users  in  the  enterprise.  This 
effort  would  provide  data  in  two  categories: 
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•  Source  data  from  authoritative  providers  that  has  been  “preprocessed”  to  correct 
errors  and  facilitate  correlation  and  seasonal  color  matching  of  data  layers. 

•  User  community  databases  produced  for  simulation  or  simulator  use  made  available 
through  a  discovery  cataloging  system  and  links  to  the  appropriate  storage  site. 

Leveraging  and  partnering  in  NGA’s  Foundation  GEOINT  3D  initiative  may  provide 
such  means. 

b.  Mid-term  actions  (CY2021): 

(1)  Support  SISO  in  developing  a  common,  detailed  environmental  features 
description.  This  entails  identification  of  object  instances  and  classes  (such  as  features, 
3D  objects,  and  textures)  within  the  common  library,  the  choice  of  semantics  and 
mapping  with  existing  dictionaries,  and  the  linkages/semantics  between  instances  and 
classes.  The  follow-on  RIEDP  Product  Development  Group  (PDG)  proposed  two 
products  for  SISO  adoption  (SISO-PN-007-2013  VI. 3  of  4  January  2013)  consisting  of: 

•  An  Environmental  Data  Model  Foundations,  which  will  serve  as  a  SISO  Guidance 
document.  The  data  model  would  be  composed  of  two  tightly  coupled  parts,  the 
Reference  Process  Model  (RPM)  and  the  Reference  Abstract  Data  Model  (RADM). 
These  form  the  foundations  for  existing  and/or  emerging  database  generation 
projects  to  compare,  contrast,  and  map  their  data  generation  process  and  data  model 
capabilities  to  these  models. 

•  An  Environmental  Detailed  Features  Description,  which  will  be  a  SISO  Standard 
product.  The  description  will  provide  the  required  information  for  identifying 
instances  and/or  classes  of  environmental  features  and  objects  that,  along  with  their 
specific  attributes,  value  ranges,  and  metadata,  will  be  utilized  in  environmental  data 
products.  The  use  of  the  Environmental  Detailed  Features  Description  as  a  standard 
product  will  ensure  data  interoperability  through  the  identification  of  features,  their 
definitions  (through  the  use  of  standardized  dictionaries),  their  corresponding 
attributes,  and  any  associated  metadata. 

Both  products  may  improve  reuse  and  interoperability  of  environmental  data  and 
processes;  and  the  training  community  may  benefit  in  participating  in  the  development 
of  the  standard  as  applicable  toward  accomplishing  this  action. 

(2)  Establish  a  consensus  on  attributes  and  attribution  rules  for  the  training 
community.  Preferably,  an  existing  attribution  schema  suitable  to  training,  exercise, 
and  mission  rehearsal  would  be  used,  rather  than  developing  one  unique  to  the  training 
community.  Initially,  this  would  involve  the  identification  of  a  common  list  of  features 
and  attributes  (concept,  range  of  values,  application  domain),  using  standard 
dictionaries,  to  be  associated  to  the  environmental  objects  (classes  and  instances).  In  the 
long  term,  identify  and  define  common  attribution  rules  for  the  community. 

c.  Long  term  actions  (CY2021  -  2024): 
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(1)  Migrate  the  enterprise  toward  adoption  of  a  common  database  standard  or 
specification  where  it  will  not  adversely  affect  cost,  schedule,  or  performance. 

Ideally,  this  should  be  an  open,  national  or  international  standard  that  can  be  used  for 
both  offline  data  storage  and  as  a  runtime  database  format.  Enterprise  adoption  can  be 
easily  phased  to  minimize  impact: 

(a)  Phase  I:  Establish  a  framework  for  the  management  of  the  standard 

i.  The  framework  will  function  as  the  training  enterprise  body  for  the 
selection  of  the  standard. 

ii.  Post- selection  the  framework  manages  enterprise  changes  to  the  standard 
via  the  open,  community-based  process. 

(b)  Phase  II:  Common  offline  storage  format  (by  CY2021)  -  As  a  cost 
deferment,  a  common  database  standard  or  specification  can  be  initially  utilized 
for  offline  storage  only  to  avoid  the  expense  associated  with  adapting  existing 
legacy  simulations,  simulators,  and  support  tools  to  utilize  the  standard  or 
specification  natively. 

(c)  Phase  III:  Transition  constructive  simulations  to  the  common  standard  as  a 
runtime  format 

i.  New  Joint,  Service,  and  Agency  enterprise  constructive  capabilities 
should,  when  it  meets  requirements,  develop  to  the  common  database 
standard  or  specification  so  as  to  utilize  it  natively  and  accrue  the  data 
interoperability  and  processing  benefits. 

ii.  Utilization  of  a  common  database  standard  or  specification  as  a  legacy 
runtime  format  will  require  further  study  to  determine  the  best  course  of 
action,  and  any  shift  must  be  based  upon  mission  needs,  cost- 
effectiveness  and  return  on  investment.  Any  decisions  must  consider 
when  various  simulations  are  projected  to  phase  out  or  whether  they  have 
gone  into  sustainment,  since  these  older  systems  may  not  have  the 
resources  or  the  technical  compatibility  to  shift  to  a  new  common 
database  standard  or  specification.  There  may  also  be  acquisition  policy 
issues  that  must  be  addressed. 

(d)  Phase  IY:  Transition  tactical  simulators  to  the  common  standard  as  a 
runtime  format 

i.  Service  and  USSOCOM  enterprise  tactical  simulator  capabilities  should, 
when  it  meets  requirements,  develop  to  the  common  database  standard  or 
specification  so  as  to  utilize  it  natively  and  accrue  the  data 
interoperability  and  processing  benefits. 

ii.  As  with  constructive  capabilities,  utilization  of  a  common  database 
standard  or  specification  as  a  legacy  simulator  runtime  format  will  require 
further  study  to  determine  the  best  course  of  action,  and  any  shift  must  be 
based  upon  mission  needs,  cost-effectiveness  and  return  on  investment. 
Sustainment  and  acquisition  policy  issues  also  apply. 
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(e)  Phase  V :  Modify  the  common  standard  to  meet  unfulfilled  requirements  - 

is  recognized  that  a  common  standard  may  not  completely  fulfill  the 
requirements  of  every  system/platform  in  the  enterprise.  However,  enterprise 
users  should  not  reject  the  common  standard  objective  until  efforts  have  been 
attempted  to  modify  the  common  standard  to  address  any  shortfalls  (e.g., 
multispectral  sensor  support)  that  inhibit  compatibility  with  Service/Agency 
capabilities. 

Prepared  by:  Mr.  Scott  Callaway,  JS  J7/DDJT/EOD,  (757)  203-7653 

Released  by:  Mr.  Samuel  Chambers,  Data  Services  Lead,  JS  J7/DDJT/EAD,  (757)  203-7404 
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Notes 


1.  The  following  requirements  sources  are  applicable  to  the  first  foundational  attribute  (Open, 
evolving,  publicly-available,  published  standards  that  are  platform  independent): 

a)  Information  Systems  Initial  Capabilities  Document  (IS-ICD)  for  the  Joint  Training 
Synthetic  Environment  (JTSE)  of  23  Jun  2015  states  the  “JTSE  will  require  a 
common  set  of  open,  net-centric,  international  standards  and  protocols  to  support 
tool  interoperability  and  reuse.”  It  also  identifies  a  Capability  Gap  Area  for 
Information  involving  “shared,  common,  reusable  content  in  the  form  of  data  capable 
of  supporting  training  scenarios.”  The  following  associated  Capability  Gaps  (CG) 
are  applicable: 

•  CG2.1  Efficient  -  Minimize  the  time  and  resources  required  to  produce  and 
manipulate  scenario  data.  (pg.  6) 

Gap  Description:  Maintenance  of  the  current  content  management  repository  is 
resource  intensive.  Data  sources  for  events  are  incomplete  and 
compartmentalized  data  leads  to  redundant  generation  of  simulation  data. 

•  CG  2.3  Discoverable  -  Provide  search  capability  and  access  to  information  and 
services  (e.g.,  tools,  services,  data,  and  documentation). 

Gap  Description:  Trainers  lack  a  method  of  discovering  and  reusing  data 
products.  Re-use  of  tools,  services,  data,  and  documentation  reduces  the  cost  of 
reproduction,  (pg.  6) 

b)  Capability  Development  Document  (CDD)  for  Synthetic  Environment  Core  (SE 
Core)  Increment  II: 

•  Commonality  of  Systems:  SE  Core  will  be  developed  IAW  the  parameters  and 
protocols  established  by  the  LVC  TE  using  open  source  formats/software, 
standard  interfaces,  and  logistics  support  for  computer  resources  required  by  SAF 
and  exercise  management,  exercise  initialization  and  operation,  conduct  of 
AARs,  system  maintenance  and  life  cycle  support.  Software  acquired  for  SE 
Core  should  maximize  use  of  industry  standard  GOTS/COTS.  (pg.  37) 

2.  The  following  requirements  sources  are  applicable  to  the  second  foundational  attribute 
(support  runtime  applications  and  source  data  storage): 

a)  JTSE  IS-ICD: 

•  CG2. 1  Efficient  -  Minimize  the  time  and  resources  required  to  produce  and 
manipulate  scenario  data.  (pg.  6) 
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Gap  Description:  Maintenance  of  the  current  content  management  repository  is 
resource  intensive.  Data  sources  for  events  are  incomplete  and 
compartmentalized  data  leads  to  redundant  generation  of  simulation  data. 

[Indirect  linkage  under  the  assumption  that  data  produced  with  a  standard  usable 
for  both  storage  and  runtime  will  reduce  redundant  data  generation,  storage 
requirements,  and  time  required  to  produce  a  simulation  database.] 

3.  The  following  requirements  sources  are  applicable  to  the  third  foundational  attribute 
(support  rapid  data  access  by  multiple  simulations  and  services): 

a)  JTSE  M&S  Roadmap: 

•  CR  01.02.02  -  Capability  runtime  database  shall  be  capable  of  simultaneous 
access  by  multiple  users  and  applications,  (pg.  D6) 

4.  The  following  requirements  sources  are  applicable  to  the  fourth  foundational  attribute 
(support  modifying  terrain  in  runtime): 

a)  JTSE  IS-ICD: 

•  CG  2.4  Flexible  -  Dynamically  manipulate  data  and  data  services  to  match 
training  objectives,  (pg.  6) 

Gap  Description:  Current  systems  lack  flexibility  in  data  production.  Processes 
require  specialized  manpower  to  adapt  data  to  the  training  scenario  or 
commander's  objectives. 

b)  JTSE  M&S  Roadmap 

•  CR  01.05.12  -  Capability  simulated  terrain  man-made  structures  will  be  subject 
to  deformation  or  destruction  by  the  actions  of  simulated  forces  (e.g.  weaponry 
blast  effects),  (pg.  D15) 

•  FR  02.04  -  Function  shall  provide  authoritative,  dynamic  correlated  terrain  data 
during  runtime  for  planning  and  execution,  including  visualizations  of  maps 
(e.g.,  Google  Earth  like  map  search),  and  dynamically  update  map  layers 
filterable  by  roles.  Allow  the  ability  to  conduct  target  specific  analysis  of  what 
terrain  features  exist  in  the  simulation  database  publish  the  digital  terrain  to  all 
federates,  (pg.  E3) 

c)  SE  Core  CDD  Increment  II: 

•  The  SE  Core  capability  must  enable  the  user  to  enhance  selected 
features/attributes  with  value  added  or  updated  information  during  training,  (pg. 
38) 
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d)  Capability  Production  Document  (CPD)  for  Joint  Land  Component  Constructive 
Training  Capability  (JLCCTC)  Increment  II: 

•  CPD  Paragraph  12.d.,  Attribute  Technical  Control:  Magic  capability  -  move, 
supply,  reconstitute,  engineer,  repair,  damage,  decontamination, 
terrain/environment  manipulation.  Threshold  =  Objective 

5.  The  following  requirements  sources  are  applicable  to  the  fifth  foundational  attribute  (support 
dynamic  terrain  and  revision  history): 

a)  Training  Gaps  Analysis  Forum  (TGAF)  Prioritized  Gaps  List 

•  TG03  -  Provide  Faster/Higher  Fidelity  Scenario  Database  Generation  (ranked  6 
of  12) 

o  Accurate  replication  of  weather  conditions  and  effects  -  Realistically 
impact/degrade  weapon  and  sensor  system  operations  and  performance 
characteristics 

o  Produce  Terrain  databases  (geospatial  and  weapons  effects  results)  consistent 
across  all  federates  in  the  LVC  environment  -  Includes  the  simulation 
capability  to  dynamically  modify  the  terrain  environment  during  runtime  (e.g. 
building  damage,  fighting  positions,  runway  cratering,  etc.)  and  apply  the 
results  consistently  across  an  LVC  federation. 

b)  JTSE  IS-ICD: 

•  CG  2.4  Flexible  -  Dynamically  manipulate  data  and  data  services  to  match 
training  objectives,  (pg.  6) 

Gap  Description:  Current  systems  lack  flexibility  in  data  production.  Processes 
require  specialized  manpower  to  adapt  data  to  the  training  scenario  or 
commander's  objectives. 

c)  JTSE  M&S  Roadmap: 

•  CR  01.05.12  -  Capability  simulated  terrain  man-made  structures  will  be  subject 
to  deformation  or  destruction  by  the  actions  of  simulated  forces  (e.g.,  weaponry 
blast  effects),  (pg.  D15) 

•  FR  02.04  -  Function  shall  provide  authoritative,  dynamic  correlated  terrain  data 
during  runtime  for  planning  and  execution,  including  visualizations  of  maps 
(e.g.,  Google  Earth  like  map  search),  and  dynamically  update  map  layers 
filterable  by  roles.  Allow  the  ability  to  conduct  target  specific  analysis  of  what 
terrain  features  exist  in  the  simulation  database  publish  the  digital  terrain  to  all 
federates,  (pg.  E3) 

•  FR  04.01.01  -  Function  shall  maintain  a  running  log  (i.e.,  record  over  time)  of 
database  changes  and  interactions,  (pg.  E4) 
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d)  SE  Core  CDD  Increment  II: 

•  KPP  4  Dynamic  Environment  -  Threshold:  Dynamic  physics-based 
approximations  of  the  natural  and  man-made  environment,  to  include  effects  of 
munitions,  lethal/non-lethal  entity  actions,  exercise  controller  actions, 
atmospherics  conditions,  localized  weather  effects,  radio  frequency  modeling, 
and  Chemical,  Biological,  Radiological,  Nuclear,  and  High  Explosive  (CBRNE). 
These  approximations  must  be  rendered  in  the  visual  representation  as  well  as  all 
other  affected  CVE  attributes. 

Objective:  Dynamic  environment  will  be  upgradable  to  incorporate  future 
physics-based  approximations  of  the  natural  and  man-made  environment,  to 
include  effects  of  munitions,  lethal/non-lethal  entity  actions,  atmospheric 
conditions,  radio  frequency  modeling,  and  CBRNE.  Interoperable  and  correlated 
with  unified  action  and  Army  LVCTE  dynamic  synthetic  natural  environments. 

Rationale:  Dynamic  Environment  is  essential  to  creating  a  realistic  LVC  TE  that 
allows  units  to  train  as  they  fight  in  a  realistic  synthetic  natural  environment. 
Actions  taken  by  units,  damage  caused  by  munitions  and  atmospheric  effects 
change  the  environment  during  operations.  The  common  virtual  environment 
must  account  for  changes  to  the  environment  to  accurately  reflect  the  actions  of 
the  combined  arms  team.  Dynamic  environment  is  necessary  to  approximate 
those  effects  to  add  realism  in  the  LVC  TE.  This  is  a  requirement  for  effective 
virtual  TADSS  [Training,  Aids,  Devices,  Simulators,  and  Simulations],  (pgs.  11 
and  16) 

6.  The  following  requirements  sources  are  applicable  to  the  sixth  foundational  attribute 
(support  procedural  geometry):  Unable  to  trace  to  a  specific  Service  or  Joint  requirement  at 
this  time. 

7.  The  following  requirements  sources  are  applicable  to  the  seventh  foundational  attribute 
(support  global  coverage/multiple  levels  of  detail): 

a)  JTSE  IS-ICD: 

•  Capability  Gap  Area:  Environment  -  An  integrated  LVC  capability  that  enables 
Joint  training  across  the  full  range  of  military  operations  when  and  where  needed 
by  accurately  replicating  complex  operational  environments  at  the  necessary 
levels  of  detail  to  meet  readiness  objectives,  (pg.  5) 

•  CG  1.6  Agile  -  Provide  LVC  environments  that  quickly  adapt  to  operational 
need. 

Gap  Description:  Current  tools  cannot  quickly  adjust  fidelity  and  resolution  to 
meet  operational  need.  Modular  and  interoperable  capabilities  that  allow  rapid 
tailoring  are  required  to  achieve  training  objectives.  Developing  a  flexible, 
scalable  architecture  for  the  simulated  environment  will  allow  composition  and 
outputs  tailored  to  the  training  audience  and  objectives  identified  before  and 
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during  events.  [While  the  gap  describes  service  and  architectural  capabilities  that 
enable  rapid  tailoring  of  fidelity  and  resolution,  data  and  database  production 
must  support  these  capabilities]  (pg.  6) 

b)  JTSE  M&S  Roadmap 

•  CR  01.05.11  -  Capability  shall  be  able  to  tailor  the  size  and  fidelity  of  the  play 
box  to  meet  training  objectives  (e.g.,  world-wide  representation  to  support 
Globally  Integrated  Operations),  [metric  specifies  1  meter  to  1:250,000]  (pg. 

D15) 

•  FR01 .02.01  -  Function  shall  provide  visualization  of  standard  multi-resolution 
map  formats  and  imagery  (e.g.,  separate  and  unified  training  COP  of  simulation 
and  C2).  (pg.  El) 

•  FR04.07  -  Function  shall  establish  production  Unclassified/Classified  repository 
or  library  of  correlated  terrain  simulation  data  (e.g.,  roads,  hydrology,  urban 
boundaries,  and  point  features)  in  one  common  format  for  use  and  reuse.  Library 
will  provide  level  "low  resolution"  terrain  data  converge  over  the  globe  and 
higher  resolution  geospatial  data  in  selected  areas  for  each  COCOM  according  to 
priorities,  (pg.  E5) 

c)  SE  Core  CDD  Increment  II: 

Paragraph  7  Family  of  Systems  (FOS)  and  System  of  Systems  (SOS)  Synchronization  Table  4  - 
Capability:  Contributes  to  the  Joint  Training  Functional  Concept  and  Army  Training  Mission  area 
by  providing  appropriate  levels  of  modeling  and  simulation  resolution  and  fidelity  needed  to 
support  training. 

CDD  Contribution:  SE  Core  can  support  the  requirements  of  JLCCTC  simulation  ready  terrain 
database  development  for  operational  training  exercises,  up  to  and  including  the  representation  of  a 
theater-equivalent  battlespace  with  Joint  assets  and  effects  that  involve  Army  systems  and  activities, 
in  Constructive  simulation  as  required,  (pg.  26) 
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Runtime  Publishing  Format 

Geospatial  Source  &  Industry  Formats  Utilized  by  the  Specification 

Organization 

Terrain 

Generation 

Capability 

Specification 

Specification  Category 

Source  Data  Repositon 

Standardized  Schema  & 

Attributes 

Platform  Independenl 

Operating  System 

Independent 

Transport  Protocol 

Independent 

Utilizes  WGS-84  Earth 

Model 

TIFF 

_ A 

DTED 

_ A 

Geo-TIFF 

_ A 

OpenFlight 

_ A 

Shapefile 

_ A 

RGB/RGBA 

_ A 

JPEG 

DDS 

_ A 

DXTn 

_ A 

FXTn 

_ A 

JPEG  2000 

_ A 

XML 

GeoPackages 

CityGML 

d 

JSJ7 

Terrain 

Common  DataBase  (CDB) 

Open 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

No 

Marines 

Generation 

International 

8 

9 

9 

10 

5 

4 

3 

1 

1 

1 

1 

1 

2 

2 

SOCOM 

Service  (TGS) 

Standard 

&  SOFPREP 

6 

Army 

Synthetic 

Master  Database  (MDB) 

Government 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

Yes 

No 

No 

No 

Yes 

Yes 

No 

No 

Environment 

Standard 

8 

11 

Core 

7 

(SE-Core) 

Air  Force 

Air  Force  Common 

Government 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

No 

Dataset  (AFCD) 

Standard 

7 

8 

1 

1 

1 

1 

1 

Navy 

NAVAIR  Portable  Source 

Government 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

No 

Initiative  (NPSI) 

Standard 

7 

8 

1 

1 

1 

1 

1 

Notes: 

1.  Included  in  the  OpenFlight  texture  pattern  formats. 

2.  Expected  in  CDB  Version  2  release. 

3.  CDB  V2.0  may  replace  Shapefile  format  with  other  OGC  formats,  e.g.  Geopackage. 

4.  CDB  V2.0  may  replace  OpenFlight  with  other  OGC  formats,  e.g.  CityGML. 

5.  CDB  can  read  DTED,  but  stores  the  data  as  a  Geo-TIFF. 

6.  CDB  has  undergone  an  18-24  month  vetting  by  an  international  standards  body  (OGC)  and  has  been  adopted  as  an  open,  accredited  standard  (CDB  1.0)  on  September  23, 
2016. 

7.  Service-specific. 

8.  While  all  fourspecifications  have  standardized  schema  and  attributes,  CDB  is  the  only  specification  that  has  been  vetted  by  an  open  international  standards  body  and  has 
been  approved  as  an  OGC  standard. 

9.  The  constraints  imposed  by  the  CDB  Specification  are  minimal  and  are  designed  to  allow  its  implementation  on  any  of  the  widely  available  computer  hardware  platforms, 
operating  systems,  file  systems  and  transport  protocols. 

10.  CDB  is  the  only  specification  of  the  four  that  is  structured  with  multiple  Levels-of-Detail  (LOD)  and  tiled  in  such  a  manner  as  to  promote  efficient  storage,  access,  and 
transportation.  The  CDB  Specification  also  prescribes  the  use  of  an  industry  standard  compression  algorithm  for  its  storage  intensive  raster  imagery  datasets.  This  not  only 
provides  a  substantial  reduction  in  storage,  but  also  reduces  the  data  transmission  bandwidths  associated  with  simulator's  access  to  the  synthetic  environment  database  at 
runtime. 

11.  SE  Core  is  pursuing  Geopackage  as  the  replacement  for  Ooenflieht  and  sUrNISlLASSIFIED 
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